home *** CD-ROM | disk | FTP | other *** search
- These notes are extracted from the protracker 1.2 source and other places.
-
- Counter goes 1 .. 2 ... currentspeed ? -> 0
- Actual commands occur for counter = 0, effects occur only for counter > 0.
- Big difference with Med there, except when in soundtracker compatibility mode.
-
- Samples:
- usual sample length unit is the 16 bit memory word, except for some real old
- tracker tunes, which use bytes for the replay offset ???
- Consequently, this should only occur with 15 instruments modules (not checked
- for in tracker). The actual check is whether rp_length + rp_offset is greater
- than length. Usual protracker samples are 8-bit signed (dictated by the
- amiga hardware).
-
- Finetune:
- it seems the stored frequencies are actually notes, i.e., they
- always correspond to the base frequency table.
- So what you do is convert the frequency to notes as usual, then
- use another frequency table according to the finetune setting.
-
- Arpeggio 1: on Counter % 3 ,
- 0 normal
- 1 +HI
- 2 +LO
-
- Portamento up 1/down 2: there is NO default value. Accordingly, 0 does nothing.
- Note that we ensure $71 <= period <= $358. And 0 <= volume <= 64
-
- Tone portamento 3/Tone porta+ vol slide 5: work exactly the same way except that
- 5 doesn't have a rate, but use the previous rate.
- Various cases:
- - new note: porta to the new note with the given (or previous) rate.
- Start with the current period, not any previous goal or anything.
- - no new note: go on tone portamento, unless already finished. If needed,
- adjust rate on the fly.
-
- Gliss funk E3: snap the actual pitch to the nearest note. Don't store it.
-
-
- Fine porta up E1/Fine porta down E2/Fine volume up EA/Fine volume down EB:
- do just one change, on setup.
-
- Set speed: under protracker, 0 does stop.
- < 32 does a normal set counter.
- >=32 is a factor to get real speed from (default is 125), except for old
- tracker modules.
- what to do when there are several set speed command in the same line ?
- First, if all set_speed options are in the same mode (<32 for instance),
- only the last one applies.
- Opinions differs... it seems that even various incarnations of protracker
- don't do the same thing. tracker behavior changes according to the speedmode
- option:
- * old -> all set_speed just do a normal set counter.
- * finefirst -> only the >=32 command is heeded.
- * normalfirst -> only the < 32 command is heeded, AND finespeed is reset to 125
- * normal -> both commands are heeded.
- note that protracker behavior states that set_speed(<32) should reset finespeed
- to 125.
-
-
- Change volume B: the value is pure binary.
-
- Volume Slide A: delta = HI - LOW. No default value.
- The actual code does: HI == 0 ? -LOW : +HI
-
- Sample offset 9: take parameter x 256 and start from there (if
- para x 256 >= length, just don't play sample).
-
- Note cut EC/ Note Delay ED: occurs when counter = para
-
- ---------
- Some comments about resampling:
- any profiler will tell you that tracker spends most of its time emulating
- the amiga hardware in resample.c (except on the amiga, of course).
- What can be done to alleviate the problem ?
-
- - on any machine that has got hw sufficiently similar to the amiga (at least
- four channels and independent replay speed), write routines similar to the
- amiga.
-
-
- - keep it simple... Even a stupid test might slow the routine down. Hence,
- the duplicated code according to oversample, the special `empty' sample with
- its special properties (samp->fix_length == 0 && samp->rp_start == NULL).
-
- As a consequence, new sample styles (like 16 bit samples) SHOULD be implemented
- as new types of commands like DO_NOTHING, PLAY, REPLAY (PLAY16 and REPLAY16
- come to mind), even though it WILL duplicate loads of code.
-
- Recently, the code has changed to allow for more than four channels. This incurs
- a slight overcost (two more additions), which is actually negligible for
- oversampled replay, and has been deemed acceptable for simple replay.
-
- The lookup table for converting 0-64 volumes to a linear scale is a cheap way
- to allow for all sorts of manipulations on the sample volumes at a low cost,
- and also to use n-bit samples in an almost transparent way, even with n not
- being an integral multiple of 8.
-
-
-
-
- If your machine is REALLY slow, and uses ulaw, computing a complete lookup
- table (all 16384 values of it) might speed things up somewhat. Removing the
- oversampling test altogether might do it also. Then you can unroll the
- for(i = 0; i < number; i++) loop, not initialising value[LEFT_SIDE] and
- value[RIGHT_SIDE] to 0, but giving them their initial real value.
- If all that fails, you can still find a better compiler, check whether your
- audio bandwidth is not too limited, downgrading the audio output to a lower
- acceptable frequency (stuttering and outputting several times the same
- sample is possible). Lastly, you can still go to assembly language...
-
- Some optimization has been added to resample/audio.c. Basically, I've checked
- where tracker was spending time, and I discovered that ALMOST all the time
- was spent doing divisions/multiplications, like for primary, secondary.
- Instead of computing:
- realLeft = left*primary + right*secondary
- realRight = right*primary + left*secondary,
-
- doing
- sum = (left+right) * (primary+secondary)/2
- diff = (left-right) * (primary-secondary)/2
- realLeft = sum+diff
- realRight = sum-diff
-
- gains two multiplications ! Just realize that (primary+secondary)/2 and
- (primary-secondary)/2 don't change and can be precomputed.
-
- Apart from primitive architectures where multiplication and addition costs
- are the same, this gains a lot. On a sparc 5, I can now use -over 2 -freq 44 !
-
- The `Next Generation' will probably be output-size aware and not compute
- 23 bits systematically, but ask what resolution the audio output uses,
- and output left/right samples with a given number of bits, stating the
- number of bits at the same time.
-
- ---------
- Amiga HW details:
-
- Since part of the behavior of soundtracker-like programs depend heavily on the
- amiga audio hardware, it is only suitable that there be a description of this
- hardware here.
-
- The amiga has four completely independant audio channels, numbered from 0 to 3.
- Channel 0 and 3 are connected to the left-side stereo output, 1 and 2 to
- the right-side---hence the strange numbering in soundtracker programs.
-
- Sound data is 8 bit signed in standard 2 complement (-128<=v<=127).
-
- The volume is also set independently from 0 to 64 (0<=v<=64).
- There is no typo there ! In terms of the hardware, the 64 value means that the
- hardware dampening is disconnected.
- The volume is linear. Sample values as follows:
- Volume db
- ---------------
- 64 0
- 48 -2.5
- 32 -6.0
- 16 -12.0
-
- The sampling period is limited by the number of DMA cycles allocated to an
- audio channel, and traditionally linked to the video frequency. The formulas
- are of little interest. The result is used in notes.c for instance.
-
- Finally, the amiga features a low-pass filter that can be disconnected through
- software. The filter becomes active around 4KHz and gradually begins to attenuate
- the signal. Generally, you cannot hear frequencies higher than 7KHz.
- Most soundtrackers disable the low-pass filter, and use it only for special
- effects.
-